home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / tcl / workshop / tcl93pr1.lha / tcl93-proceedings2 / session3 < prev   
Text File  |  1993-06-14  |  7KB  |  148 lines
  1. Article 4750 of comp.lang.tcl:
  2. Newsgroups: comp.lang.tcl
  3. Path: chemabs!malgudi.oar.net!caen!saimiri.primate.wisc.edu!ames!agate!pasteur!sprite.berkeley.edu!asah
  4. From: asah@sprite.berkeley.edu (Adam Sah)
  5. Subject: Tcl'93 Future Directions Session 3 notes.
  6. Message-ID: <1993Jun13.184606.12638@pasteur.Berkeley.EDU>
  7. Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
  8. Nntp-Posting-Host: treason.berkeley.edu
  9. Organization: University of California, at Berkeley
  10. Date: Sun, 13 Jun 1993 18:46:06 GMT
  11. Lines: 133
  12.  
  13.  
  14. What follows are notes I made during the "Future Directions" session #3,
  15.   led by John Ousterhout, during the Tcl'93 Workshop.  Each session had a
  16.   "main topic" of discussion, plus an open period where he solicited random
  17.   suggestions for improving the language.
  18.  
  19. Main topic: security.
  20. ---------------------
  21. I. John's slides (these are more or less verbatim from his slides- the
  22.     peanut-gallery commentary is at the bottom)
  23. 1. Evaluating Untrsuted Scripts - cover
  24. 2. Introduction
  25.     goal: use tcl scripts as a gen. purp. method of interchange:
  26.         - among app's on a display.
  27.         - active email (eg. surveys)
  28.     security problems:
  29.         - tcl is powerful (file access)
  30.         - evil scripts can do great harm.
  31.     solution:
  32.         - twin interpreters (like user/kernel space in os's)
  33.         - protected calls between them (like system calls)
  34. 3. Twin Interps
  35.     - trusted interp- used by app/user: has full access to all tcl cmds
  36.     - untrusted interp- used to exec incoming (suspicious) scripts- all
  37.         dangerous cmds removed.
  38.     - new cmds in trusted interp:
  39.         set evil [safetcl create]
  40.         $evil eval $script
  41.     - untrusted interp won't be able to do much that's useful, though.
  42. 4. Safe Calls
  43.     Allow untr. interp to impl. restr'd new fun's for untr. interp:
  44.     - restr'd file access, sending mail...
  45.     - analogous to system calls.
  46.     Mechanism: cmd in untrusted interp that causes exec of cmd in trusted
  47.           interp.
  48.     - in trusted interp:
  49.         set evil [safetcl create]
  50.         $evil safecall sendmsg checksend
  51.     - in untr'd interp:
  52.         sendmsg $to $body
  53.     - subst's must occur in untr'd interp!
  54.     - checksend exec'd in tr'd interp with fully-subst'd args.
  55.     - result/error retn'd to untr'd interp.
  56. 5. Safe Calls (cont'd)
  57.     Proc's that impl. safe calls must be very careful:
  58.     - never eval arg as tcl script or tcl expr!
  59.     - check filenames before read/write files.
  60.     - never exec shell cmds specified in args w/o careful checking first.
  61.     - when in doubt, ask user for permission (but not too much, or else this 
  62.         technique loses effectiveness, as users are constantly saying "OK"
  63.         to everything)
  64.     result: safe calls hard to write and certify.
  65.     but, for max power, wants lots of safe calls avail.
  66.     need mechanism for certifying and distributing safe calls.
  67. 6. Certifying Safe Calls
  68.     Use encryption techniques (digital sigs):
  69.     - central, trusted, netw auth. writes new safe calls, certifies them
  70.       with dig. sig, distr's publically.
  71.     - anyone can fetch cert'd safe calls, check sig, install locally w/o fear.
  72.     - active email msg (untr'd) can contain new safe calls as part of
  73.       untr'd script.
  74.     - untr'd script invokes existing safe call to make new safe call
  75.     - in tr'd interp, verify sig of incoming safe call before installing.
  76.     Can extend mech. to have local cert. auth's as well as global.
  77. 7. Other apps
  78.     Safe Call mech. suitable for many other things besides active email:
  79.     - restrict incoming 'send' cmds in tk.
  80.     - in commercial product, restrict access by customers to internal cmds.
  81.     - in device control apps, don't allow userstotal control over devices
  82.       (could be dangerous)
  83.  
  84. II. Comments  (where possible, I made a note of who said what, so followup is
  85.   possible- if no name is present, then it means that I didn't catch the
  86.   speaker quickly enough...)
  87.     John: example of GUI for untr'd Tk apps: have untr'd windows be
  88.   children of tr'd windows in Tk- then add speckled border to mean "don't
  89.   trust me!", plus a 'kill' button that always gets rid of window (which
  90.   would also handle the 'grab' problem...)
  91.  
  92.     - resource limits on untr'd interp? (ie. disk, cpu, mem usage?)
  93.     - John: safety is more important than res. limits (which most OS's
  94.       still handle ok w/o sec. holes)
  95.     - Karl: _never_ call eval on stuff from untr'd script (based on his
  96.       impl.)
  97.     - John: must strip _all_ I/O (otherwise untr'd script could gen own
  98.       file handle, etc.)
  99.         ==> ok to make untr'd interp separate process (the arg that file
  100.   handles aren't valid across process boundaries isn't valid- you wouldn't
  101.   want to give away real file handles anyway)
  102.     - adam: important to have test suites for security- won't stop new
  103.   holes, but will stop old and common holes from appearing as a result of
  104.   new features/changes.
  105.     - active email can install new safecalls- safe calls can be
  106.   "autoloaded" from a well-known site storing them (via email)- ie. in
  107.   active email, if a msg is dep. on a safecall not installed locally, you'd
  108.   get a "waiting for script..." msg and the new script could be telnet'd,
  109.   ftp'd, or emailed...
  110.     - need multiple levels of trust (alt. trusted sites and sources)
  111.     - exper. from MIME- the 1st released version must be good enough, bec.
  112.   commercial sites might not be able to receive these updates.  good
  113.   enough= useful for 99% of all stuff, ie. active msgs.
  114.     - auditing/logging of active email etc.?
  115.     - adam: have an _unsafe_ call library, not just a safe call lib-
  116.   question of whether it makes more sense to have large libraries of safe
  117.   calls, or large lib's of unsafe calls (latter will be slower to exec,
  118.   since need checking, but former are more prone to sec leaks and need
  119.   verification etc.)
  120.     - templates for active email (a standard form called a "sruvey" and
  121.   users can declare options for how it will look and behave within that
  122.   style).
  123.  
  124. misc:
  125.     - wayne christoper: hard to debug 'trace' if there's an error in the
  126.   trace procedure.  someone: use "after 1" to get you out of that.
  127.     - can't rerun error msgs.
  128.     - need: error msg after write traces.
  129.     - need: access to value _before_ write traces.  john: diff to impl.
  130.     - an "unknown" for variable access.
  131.     - use of % subst in var traces
  132.     - events on all sorts of error (user defined events).
  133.         userdef error codes (long discussion on how to impl.  john suggests
  134.   that the numeric error codes could be gen'd at runtime by a routine,
  135.   rather than by #defines.  adam: be careful- they then can't be passed to
  136.   other wish's!  john: string error codes?
  137.     - rename as an event?, retn callbacks for procedures?
  138.     - pass args by name not position to proc's?
  139.  
  140.  
  141.  
  142.  
  143. Thanks again,
  144. -A.Sah'93                     ...Adam Sah...asah@cs.Berkeley.EDU...
  145.                              It's not the voltage, it's the amperage.
  146.  
  147.  
  148.